home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20031118-20041115 / 000026_anthonypieper@cs.com_Mon Dec 1 11:35:05 2003.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Path: newsmaster.cc.columbia.edu!panix!news.maxwell.syr.edu!postnews1.google.com!not-for-mail
  2. From: anthonypieper@cs.com (newexpectuser)
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: Re: Problem in Kermit trying to get a file while sending it at the same time
  5. Date: 1 Dec 2003 06:25:58 -0800
  6. Organization: http://groups.google.com
  7. Lines: 54
  8. Message-ID: <f0bb0f39.0312010625.7751d0a7@posting.google.com>
  9. References: <f0bb0f39.0311250532.1b93aad@posting.google.com> <slrnbs6r9i.oig.fdc@sesame.cc.columbia.edu> <f0bb0f39.0311260731.11d9eb29@posting.google.com> <f0bb0f39.0311261025.6fd175b5@posting.google.com> <slrnbsa0at.dm1.fdc@sesame.cc.columbia.edu>
  10. NNTP-Posting-Host: 209.251.39.194
  11. Content-Type: text/plain; charset=ISO-8859-1
  12. Content-Transfer-Encoding: 8bit
  13. X-Trace: posting.google.com 1070288758 2185 127.0.0.1 (1 Dec 2003 14:25:58 GMT)
  14. X-Complaints-To: groups-abuse@google.com
  15. NNTP-Posting-Date: Mon, 1 Dec 2003 14:25:58 +0000 (UTC)
  16. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14702
  17.  
  18. I think I understand the following in the article:
  19.  
  20. "Notice that failure leaves the partial file (if any) in the working
  21. directory, where the central-site watcher process does not look for
  22. it. Thus transient failures do no harm. The script can be run again
  23. later.
  24.  
  25. The /DELETE switch on the PUT command removes the source file after,
  26. and only if, it was uploaded successfully; this prevents it from being
  27. uploaded again (you could also have it moved or renamed). This way,
  28. even if the script is run again for the same file, it will fail
  29. immediately because the file is no longer there. Or, if a file of the
  30. same name is in the same place, it is a new file that should be
  31. uploaded.
  32.  
  33. Now we can move the uploaded file from the server's working directory
  34. to its ready directory (the syntax assumes a UNIX-like file system on
  35. server):
  36.  
  37.  
  38.   ftp rename \m(nameonly) ../ready/\m(nameonly)"
  39.  
  40.  
  41. This solves my problem if I have a partial file, it will be transfered
  42. into a directory (working) where my central-site server won't be
  43. looking for it. Once this file has been dropped off 100%, then the
  44. next time around I run to send files, I will then pickup a full file
  45. in my working directory.
  46.  
  47. What I don't understand is with the above "ftp rename \m(nameonly)
  48. ../ready/\m(nameonly)", how does this avoid moving the partial file
  49. from the working directory to the ready directory, there will still be
  50. a file in the working directory albeit a partial file and this command
  51. will move it along to the ready directory.
  52.  
  53.  
  54.  
  55.  
  56. Frank da Cruz <fdc@columbia.edu> wrote in message news:<slrnbsa0at.dm1.fdc@sesame.cc.columbia.edu>...
  57. > In article <f0bb0f39.0311261025.6fd175b5@posting.google.com>,
  58. > newexpectuser wrote:
  59. > : My main issue is the file(s) I want are on a secure ftp server. This
  60. > : process has other companies dropping off their files off in a certain
  61. > : directory, so if they are dropping off a large file in this directory
  62. > : at the same time I am trying to get the files from this directory, it
  63. > : seems I am getting only a partial file.
  64. > : 
  65. > Please read the the FTP scripting tutorial, including the "transaction
  66. > processing" section.  I've referred you to it before.  It addresses
  67. > exactly this problem.
  68. > 
  69. >   http://www.columbia.edu/kermit/ftpscripts.html
  70. > 
  71. > - Frank
  72.